1. Field of the Invention
The present invention pertains to data access networks. More particularly, this invention relates to evaluating performance as perceived by a user/subscriber of a network connected between a data service system and a target terminal with minimized test traffic in the network.
2. Description of the Related Art
An Internet or Intranet access system typically includes an Internet/Intranet service system (ISS) and an interconnect network that connects the ISS to subscriber sites. The ISS typically includes content servers that store data for transfer to the subscriber sites. The content servers typically utilize Internet applications, such as electronic mail, bulletin boards, news groups, and World Wide Web access. In addition, the ISS may have a Proxy server that allows a network administrator to restrict access to the Internet. Another use of the Proxy server is to cache frequently accessed data from the Internet. Other components that are typical of the ISS a router or routers for routing transmissions to and from subscriber sites, and to and from global Internet and other ISSs.
The interconnect network between the ISS and subscriber sites can use a number of technologies supporting a wide range of bandwidth. For instance, subscribers in their homes may connect to the ISS via dial-up telephone lines, or via high-speed alternatives such as Integrated Services Digital Network (ISDN), Asymmetric Digital Subscriber Line (ADSL), Hybrid Fiber Coax (HFC) network, or wireless Local Multi-point Distribution Service (LMDS). Whereas dial-up lines provide transfer speeds of 2.4 kbps and greater, ISDN connections reach transfer speeds of 128 kbps, ADSL and cable modem HFC networks reach speeds up to 10 Mbps. Alternatively, subscribers in a corporation or school may use conventional local area network (LAN) technologies such as Ethernet and FDDI that support bandwidth from 10 Mbps to 100 Mbps.
However, when data transmitted over the interconnect network includes not only text files, but graphics, video and/or audio files as well, network traffic over the interconnect network is certainly increased significantly. In fact, the recent rapid growth of Internet applications, such as the World Wide Web, has significantly increased the amount of network traffic, leading to network congestion. The network congestion typically results in longer wait or inability to access the ISS from the subscribers' sites. Longer wait times may also be caused by packet errors introduced during transmissions by noise problems in the interconnect network (This is especially true for network technologies such as HFC, LMDS, and ADSL).
To maintain subscribers' satisfaction, it is necessary to monitor or evaluate the performance of the Internet/Intranet access system. Subscribers perceive performance of such a system in various ways. Data transfer (or network) throughput is one of the predominant measures of performance as perceived by a subscriber. Data transfer throughput refers to the rate at which data is reliably transferred between the ISS and a subscriber's terminal (i.e., computer or modem) via the interconnect network. For example, when a subscriber initiates a file transfer using the File Transfer Protocol (FTP), data transfer throughput is the ratio of the bytes transferred by the FTP to the total time taken for the file transfer. This computation of throughput takes into account any retransmissions that the lower Transmission Control Protocol (TCP) layer performs to ensure reliable delivery of data from the ISS to the subscriber's terminal.
Testing tools have been developed for monitoring the data transfer throughput. Typically, many of these tools (e.g., the public domain netperf tool) assess achievable throughput by simulating traffic over TCP connections established on the interconnect network between the ISS and the subscriber terminal (i.e., active throughput testing). One disadvantage associated with this type of active throughput testing is that support for special applications at the servers and/or subscribers' sites is typically required, solely for the purpose of monitoring throughput.
An alternative approach to the active throughput testing is to use passive monitoring. One example of such an approach is to instrument the FTP and HTTP (Web) servers to measure throughput during subscribers' data transactions to these servers. Although it measures the data transfer throughput without generating additional traffic, this approach is effective only when subscribers actively access the FTP and HTTP servers. Moreover, throughput as measured by this approach may be limited by the FTP and HTTP servers themselves and is therefore not an accurate measurement of the network performance.
One prior art active throughput testing tool, Treno (Traceroute Reno, developed at the Pittsburgh Supercomputing Center), overcomes the drawbacks of the above described approaches. Treno is executed from the ISS to measure downloading rates. Treno implements TCP-like algorithms in the application to avoid reliance on software support at subscribers' terminals. Treno uses UDP (User Datagram Protocol) packets of equal size as TCP data packets to emulate TCP's transport of information. By targeting these packets to unused ports on a subscriber's terminal, Treno evokes small ICMP (Internet Control Message Protocol) port unreachable error messages from the subscriber's terminal that are similar in size to TCP's generation of acknowledgments for data packets during a data transfer. By continuing to double the number of packets outstanding, Treno emulates the behavior of TCP during a data transfer. To emulate TCP's behavior when packet losses occur, either due to noise effects at the physical layer of the network, or due to network congestion, Treno implements back-off and retransmission algorithms that emulate TCP behavior.
One disadvantage of Treno is that Treno estimates the maximum throughput that a network can offer without any constraint being imposed based on the subscriber's terminal. This means that Treno does not impose a restriction on the TCP window size in use. As is known, typical TCP implementations at the ISS and the subscriber's terminal impose a bound on the TCP window size. Many personal computers bound this value to 8K bytes and the majority of workstations support window sizes up to 32K bytes. The TCP window size in use during a data transfer significantly impacts the network throughput observed by the subscribers. The effect of using different window sizes is best illustrated in FIG. 1. FIG. 1 shows the contrast between performance observed on the same network when using different maximum window size bounds. As can be seen from FIG. 1, the larger window size offers much higher network throughput in most cases.
Because Treno does not impose a restriction on the window size in use, it is clear from FIG. 1 that Treno can significantly overestimate subscriber-perceived data transfer throughput. A further drawback of using unrestricted window size is that this typically causes the network to be flooded with test traffic which may significantly impact the performance observed by subscribers during the time the network is being tested. Consequently, rather than measuring subscriber satisfaction, the use of Treno may cause further subscriber dissatisfaction because of its impact on the network.